home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ddn-news / ddn-mgt-bulletin-50.txt < prev    next >
Text File  |  1991-07-10  |  8KB  |  194 lines
  1. ********************************************************************** 
  2. DDN MGT Bulletin 50              DCA DDN Defense Communications System   
  3. 23 Dec 88                        Published by: DDN Network Info Center
  4.                                     (NIC@SRI-NIC.ARPA)  (800) 235-3155
  5.  
  6.  
  7.                         DEFENSE  DATA  NETWORK
  8.  
  9.                          MANAGEMENT  BULLETIN
  10.  
  11. The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
  12. Information Center under DCA contract as a means of communicating
  13. official policy, procedures and other information of concern to
  14. management personnel at DDN facilities.  Back issues may be read
  15. through the TACNEWS server ("@n" command at the TAC) or may be
  16. obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
  17. 10.0.0.51] using login="anonymous" and password="guest".  The pathname
  18. for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
  19. bulletin number).
  20. **********************************************************************
  21.  
  22. SUBJECT:   Worm (Benign) 
  23.  
  24. APPLICABLE OPERATING SYSTEM: DEC VMS
  25.  
  26. PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols
  27.  
  28. STATUS: Fix is enclosed
  29.  
  30. VALIDATION:  The fix has been forwarded to the CERT for validation, but
  31. validation has not been completed.  But in order to provide timely
  32. information to our subcribers, this fix is being made available "as
  33. is".  It was provided by a host administrator on the NASA SPAN/DOE
  34. HEPNET network.  We recommend that you contact your vendor and refer
  35. to the vendor documentation listed below before attempting to implement the
  36. fix.
  37.  
  38.  
  39. PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
  40. Supercomputer Center reported a Christmas Eve computer worm (not a
  41. virus) called "HI.COM".  This worm appears to be a benign Christmas
  42. greeting from "Father Christmas".
  43.  
  44. ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
  45. telecommunications community to the potential threat of worms and
  46. viruses.  However, "HI.COM" appears to be a prank and nothing more:
  47.  
  48.       (A) It only affects VMS machines connected to DECNET.
  49.  
  50.       (B) It does not use TCP/IP, thus it cannot "infect" the Internet
  51.           (or MILNET/ARPANET).
  52.  
  53.       (C) It does no harm (all it does is send a "stop computing and go
  54.           home" message after midnight on Christmas Eve).
  55.  
  56.       (D) It has safeguards against running multiple copies of itself on
  57.           the same machine.
  58.  
  59.       (E) It will terminate itself after completing its mission (at 00:30
  60.           on the 24th).
  61.  
  62. SYMPTOMS OF INFECTION: Some steps to take to determine if your system has 
  63. been infected are:
  64.  
  65.       (A) Check your accounting files and NETSERVER.LOGs in your default 
  66.           DECnet accounts for a file called HI.COM.
  67.  
  68.       (B) Check your processes for one named MAIL_178DC.
  69.  
  70. A FIX: 
  71.  
  72. There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
  73. international DECnet-based network.  The worm targets VMS machines, and
  74. can only be propagated via DECnet.
  75.  
  76. The worm itself appears to be benign, in that it does not destroy files
  77. or compromise the system.  It's purpose appears to be to deliver a
  78. Christmas message to users starting at midnight on 24 Dec 1988.  It
  79. does have a hook in it to monitor it's progress;  it mails a message
  80. back to a specific node (20.117, user PHSOLIDE) containing an identifying
  81. string of the "infected" machine.
  82.  
  83. The worm exploits two features of DECnet/VMS in order to propagate itself.
  84. The first is the default DECnet account, which is a facility for users who
  85. don't have a specific login ID for a machine to have some degree of
  86. anonymous access.  It uses the default DECnet account to copy itself to a
  87. machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
  88. copy.
  89.  
  90. There are several steps which you can take to protect yourself from this
  91. kind of attack.  The easiest (and most restrictive) is to disable the
  92. default DECnet account on your machine altogether.  This can be done with
  93. the following commands from the SYSTEM or other suitably privileged account:
  94.  
  95.     $ Run SYS$SYSTEM:NCP
  96.     Purge Executor Nonprivileged User Account Password
  97.     Clear Executor Nonprivileged User Account Password
  98.     ^Z
  99.  
  100. This requires that everyone who accesses your resources via DECnet to have
  101. a legitimate login ID or proxy login account on your machine (proxy logins
  102. are discussed in detail in chapter 7 of the "Guide to VMS System Security",
  103. see below).
  104.  
  105. You can take less restrictive steps to protect your machine while still
  106. maintaining some degree of default access.  If you wish to keep the ability
  107. for users to copy files to the default DECnet account but wish to prevent
  108. them from copying DCL command procedures there and then executing them you
  109. can issue the following commands (again from the SYSTEM or other suitably
  110. privileged account):
  111.  
  112.     $ Run SYS$SYSTEM:NCP
  113.     Clear Object Task All
  114.     ^Z
  115.  
  116. You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line
  117.  
  118.     CLEAR OBJECT TASK ALL
  119.  
  120. AFTER the line which says
  121.  
  122.     SET KNOWN OBJECTS ALL
  123.  
  124. This has the side-effect of disabling users from executing any command
  125. procedure via DECnet that the system manager has not defined in the
  126. DECnet permanent database.  These steps alone are not sufficient to
  127. prevent copies of the virus from being copied to your machine;  but they
  128. will prevent it from being executed.  To prevent copies of this specific
  129. virus from being copied to your machine you can issue the following
  130. commands (from the SYSTEM or other privileged account):
  131.  
  132.     $ Set Default your-default-decnet-directory
  133.     $ Create HI.COM
  134.     $ Stop/ID=0
  135.     ^Z
  136.     $ Set File/Owner=[1,4]-
  137.     /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
  138.  
  139. This prevents anyone from copying a file called "HI.COM" into your default
  140. DECnet account;  however, other files can be copied there unless you disable
  141. access to the DECnet object FAL (the File Access Listener) from your default
  142. DECnet account.  This can be done by creating a specific account for FAL
  143. (using the AUTHORIZE utility) with a seperate UIC, default directory, and
  144. minimal privileges and forcing the FAL object to use that account.  The
  145. following sequence of commands are an example (these commands also require
  146. that they be issued from the SYSTEM or other suitably privileged account):
  147.  
  148.  
  149.     $ Set Default SYS$SYTEM
  150.     $ Run AUTHORIZE
  151.     Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
  152.     /Password=randomstring/Device=disk-device/Directory=[some-directory]-
  153.     /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
  154.     /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
  155.     /LGICMD=SYS$SYSTEM:FALLOG.COM
  156.     ^Z
  157.     $ Run NCP
  158.     Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
  159.     Password same-random-string
  160.     Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
  161.     Password same-random-string
  162.     ^Z
  163.     $ Create FALLOG.COM
  164.     $ V := 'F$Verify(0)
  165.     $ Write SYS$OUTPUT ""
  166.     $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
  167.     $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
  168.     $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
  169.     $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
  170.     $ Write SYS$OUTPUT ""
  171.     ^Z
  172.  
  173. This sequence of commands separates the FAL account from the default DECnet
  174. account, and you can use file protections to enforce that the FAL account
  175. cannot access files in the default DECnet account and vice-versa.  The
  176. command file FALLOG.COM above will log all remote file accesses in the
  177. file NETSERVER.LOG in the directory specified for the FAL account above.
  178.  
  179. The FAL program can supply additional logging information;  contact your
  180. DIGITAL software support person for further details.
  181.  
  182. Further steps can be taken to restrict access to your system.  These
  183. steps are discussed in detail in the "Guide to VMS System Security", DEC
  184. order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
  185. entitled "Security for a DECnet Node".
  186.  
  187. For general information about this patch call the CERT or the Network
  188. Information Center at (800) 235-3155.
  189.  
  190. This represents the best information available at this time to fix this
  191. problem.
  192.  
  193.  
  194.